COMMENTS 

This Amendment is submitted in response to the Office Action dated July 5, 2006, having 
a shortened statutory period set to expire October 5, 2006. Claims 1-11, 19-35 and 37-54 are 
currently pending. 

Applicant's undersigned representative appreciates the time and courtesy extended by the 
Examiner during a September 5, 2006 teleconference. An agreement was reached that a 
teleconference would be granted to discuss the pending claims. 

Rejections Under 35 U.S.C. § 103 

In paragraph 13 of the present office action, the Examiner has rejected Claims 1-11, 19- 
29, 32-35 and 37-54 under 35 U.S.C. § 103(a) as being unpatentable over Furtney et al. (U.S. 
Patent No. 5,579,509 - "Furtney") in view of Kathail et al. (U.S. Patent No. 5,802,365 - 
'Kathail"). In paragraph 14 of the present office action, the Examiner has rejected Claims 30-31 
under 35 U.S.C. § 103(a) as being unpatentable over Furtney in view of Kathail and further in 
view of Applicant Admitted Prior Art. Applicants respectfully traverse these rejections, and 
request that they be withdrawn and all claims allowed. 

Kathail describes a method for automatically correlating a device to its appropriate 
driver. If the device does not already have a driver, then a candidate list of drivers is provided. 
Each driver from the list is sequentially tried until a driver is found that does not cause an error. 
(Kathail abstract.) A device in a device tree is automatically matched up with its appropriate 
driver according to the device's name (Kathail, col.7, lines 57-59). If the new device does not 
have a name, then a pseudo-name is made up for it (Kathail, col. 8, lines 19-22). A driver 
description for the driver then helps a device manager pick the best driver among multiple 
candidates (Kathail, col. 8, lines 64-66). Thus, replacing a driver is a simple two-step process of 
1) the driver to be replaced giving up control of the device and 2) installing the new driver 
(Kathail, col. 17, lines 57-62). If two drivers are available, then the most recent version is 
chosen (Kathail, col. 36, lines 12-13). Thus, the device asks 1) is there a driver available and 2) 
where is the most current version of the driver (Kathail, col. 42, lines 45-47)? 
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Furtney teaches comparing version numbers of multiple units of software to determine if 
the multiple units of software are compatible with one another {Furtney, abstract). 

With reference to exemplary Claim 1, the cited art does not teach or suggest "in response 
to determining that said firmware family codes are different, considering said two firmware 
images to be incompatible unless a compatibility table entry indicates otherwise," as supported 
by paragraph [0018] of the present specification in U.S. Patent Application Publication No. 
2004/0205745 Al. Neither Furtney nor Kathail addresses the issue or whether two firmware 
images are compatible based on firmware family codes. Furtney teaches confirming software 
compatibility by examining version numbers {Furtney, col. 3, lines 30-50). Kathail teaches 
matching up drivers to hardware devices according to, among other factors, the "service category 
of the family with which they [the drivers] belong" {Kathail, col. 2, lines 54-55). There is no 
teaching or suggestion in the cited art of an overriding "compatibility table entry" that indicates 
that two firmware images are compatible, despite being from different families. 

More specifically, with reference to Claim 1, the combination of the cited art does not 
teach or suggest an overriding "compatibility table entry" that indicates that two firmware 
images are compatible, despite being from different families. 

Furtney teaches the use of compatibility tables for software modules. However, in col. 4, 
lines 8-15, different versions of software are considered compatible if the new version is at a 
higher level. Specifically, Furtney states at col. 4: 

In the preferred embodiment, it is assumed that a software module at any 
arbitrary level will include the capabilities and functions of each lower level of 
that same module that are required for compatibility with other modules. Thus, for 
purposes of compatibility, a higher level of a module being verified will always 
satisfy minimum requirements for compatibility with the verifying module if any 
lower level of the module being verified satisfies such compatibility requirements. 
(Emphasis added.) 
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Thus, there is a presumption in Furtney that two differently named modules ARE 
compatible (assuming that the new version has a higher level), even though they have different 
names. There is no presumption ("in response to... considering") that the two versions are 
incompatible. 

With reference to Claim 35, the cited art does not teach or suggest "in response to 
determining that said installed firmware does not have a firmware family control block that 
includes a firmware family code, firmware stepping level and compatibility table for said 
installed firmware, causing a flash utility to refuse to install said candidate firmware," as 
supported in the present specification at paragraph [0037]. Specifically, there is no teaching or 
suggestion in the cited art for making installation of new firmware dependent upon the old 
firmware having a firmware family control block. 

More specifically, the combination of the cited art does not teach or suggest the feature of 
making installation of new firmware dependent upon the old firmware having a firmware family 
control block that specifically includes these three elements (firmware family code, stepping 
level and compatibility table). Kathail is cited at col. 24, lines 39-42 for this teaching. However, 
this passage only teaches that an error message should be sent if a compatible driver cannot be 
found for a specific device, and doesn't appear to suggest the claimed limitations. 

With reference to Claim 53, the cited art does not teach or suggest the additional step in 
Claim 35, wherein "in response to determining that said candidate firmware is desired to replace 
said installed firmware that does not have said firmware family control block, issuing an override 
command from said flash utility to override said refuse to install command, wherein said 
candidate firmware flashes over said installed firmware despite said installed firmware lacking 
said firmware family control block," as supported in the present specification at paragraphs 
[0037] and [0040]. That is, even if the flash utility has refused to install the new firmware, an 
override command can be issued forcing the flash utility to install the new firmware anyway. 

Kathail is cited at col. 24, line 55 to col. 25, line 25 for teaching this feature. However, 
this passage appears to be related to matching drivers to devices as soon as the driver is 
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accessible on either a hard drive or a boot ROM. Kathail does not teach or suggest that a flash 
utility is forced to install new firmware despite its initial refusal to do so (because the firmware 
didn't have a firmware family block that includes a firmware family code, firmware stepping 
level and compatibility table). 

With reference to Claim 54, the cited art does not teach or suggest "wherein said method 
for identifying compatibility between two firmware images is performed in response to an 
electronic device having undergone a design upgrade that incorporates new components," as 
supported in the present specification at paragraph [0036]. That is, firmware image 
compatibility checking is performed whenever a system upgrade of hardware is performed. 
Kathail teaches at col. 25, lines 15-16 that a new set of drivers can be introduced for devices, and 
new drivers can be introduced later (col. 25, lines 20-21). However, there does not appear to be 
a suggestion that compatibility between firmware images (not firmware (driver) and device)) 
occurs "in response to" new hardware being added. 

As the cited prior art does not teach or suggest all of the claims features in the presently 
presented claims, Applicants respectfully request that all pending claims be allowed. 
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CONCLUSION 



Applicants now respectfully request a Notice of Allowance for all pending claims. 

No extension of time for this response is believed to be necessary. However, in the event 
an extension of time is required, that extension of time is hereby requested. Please charge any 
fee associated with an extension of time as well as any other fee necessary to further the 
prosecution of this application to IBM CORPORATION DEPOSIT ACCOUNT No. 50-0563. 



Respectfully submitted, 




James E. Boice 

Registration No. 44,545 

DILLON & YUDELL LLP 

891 1 North Capital of Texas Highway 

Suite 2110 

Austin, Texas 78759 

512.343.6116 

ATTORNEY FOR APPLICANT(S) 
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